Version
1.0
Author
mmrack
Description
Este processo mostra o ciclo de vida das features em um projeto de fabrica software balizado pelo Processo 3PUP da 3layer Tecnologia. Uma feature é um item de projeto que representa valor agregado para o usuário final e que consome recursos de projeto para ser desenvolvido.
Um exemplo de feature pode ser um relatório, uma tela de sistema, uma nova operação em uma tela do sistema, uma permissão de acesso, um novo menu de tela, uma integracao... enfim, qualquer coisa que represente valor de negócio para o usuário final do projeto.
Todas as features iniciam como uma lista de desejos, como uma idéia vaga e imprecisa, que vai sendo refinada e então entra para o planejamento do projeto, tendo um lugar no cronograma, no aspecto financeiro, um responsável na equipe, etc. Após, planejada, a feature entra para o projeto técnico, onde será estudada, detalhada e um conjunto de procedimentos de testes estará definido. Após isso, ela vai para a construção física pela equipe de desenvolvedores e então para a validação final do usuário.
Se aceita pela validação, ele é entregue e então efetivamente ela agrega valor ao projeto.
Por outro lado, ela pode ser cancelada em qualquer parte do processo e então não agrega valor ao projeto.
Caso, durante o desenvolvimento algum problema ocorrer que ela nao possa ser concluida com sucesso, a feature precisa ser devolvida. Uma vez que essa devolucao pode impactuar todo o projeto, a devolucao eh realiza diretamente para o ponto de inicio do projeto, ou seja, ela volta para a definicao. Independente de existirem problemas no tocante a definicao, planejamento ou outro, ela deve passar obrigatoriamente por todos esses passos novamente, para todos os envolvidos terem ciencia (conhecimento) desse fato. Por esse motivo que a feature retrocede todo o workflow sempre.
Para mais informações sobre esse ciclo de vida, acesse o post http://telasdecadastro.blogspot.com/2010/04/o-ciclo-de-vida-das-features-no.html
Description
Por qualquer motivo, a feature pode ser cancelada, e a qualquer momento.
Quem decide pelo cancelamento de uma feature é, exclusivamente, o PO.
Embora a equipe pode achar que a feature seja inimaginavelmente complexa ou irreal, isso não importa, pois o PO pode assim mesmo a desejar e disposto a esperar e pagar por isso.
Assim, cabe somente ao PO cancelar uma feature.
O ScrumMaster, o Time e seus Chief Programmers podem, porém, persuadiar o PO para que ele cancele features que não estejam em sintonia com o projeto.
Description
A Feature foi construída e entregue, e está funcionando perfeitamente no sistema, conforme o PO desejava desde o início do projeto.
Description
O Product Owner identificou que precisa de algo no projeto, mas ainda está incipiente.
O Time e o Product Owner trabalham da definição da feature, buscando saber em que parte do projeto este "algo" se encaixa, ou mesmo se ela vai ser uma Feature mesmo ou então um módulo novo, um Serviço, um Set ou um fragmento de funcionalidade que precisa ser incorporado em uma Feature já existente ou, em outra vertente, se este algo não vai fazer parte do projeto ou mesmo se ele vai ser um projeto em separado!
Para sair desse status, a Feature precisa:
1. Ter um nome (no padrao A.A.R.O.)
2. Ter um local para ser encaixada (Modulo, Servico e Set)
3. Ter uma descricao geral, em um parágrafo.
4. Ter um dono (isso deriva do padrao AARO acima, e indica que ela tem um usuario ou grupo de usuarios que vao utiliza-la no sistema quando o projeto for entregue - ou seja, uma role que identifca quem utliiza a feature)
5. Ter um conjunto de requisitos que a balizam (podem ser textuais, genericos, mesmo sem grande formalismo, mas que norteiem claramente sua complexidade e escopo - lembre-se, quanto mais tempo for dedicado para isso nessa fase, mais subsidios ter-se-ao na etapa seguinte, de planejamento).
Performers
Description
A feature esta com escopo definido e entrou para a etapa de planejamento, onde vai ser transformada em um elemento de projeto - uma tarefa de projeto.
Nesse momento o PO, o Time e o ScrumMaster vao definir, e ela somente pode sair desse status se:
1. Tiver um dono no projeto (um Chief Programmer da FDD - geralmente um analista de negocio responsavel ou um projetista responsavel), que vai ser responsavel por ela, respondendo por ela, durante todo o ciclo de vida do projeto
2. Ter um tamanho, mensurado em Feature Points (o que sugere que também é mapeado seu tamanho em horas-homem), o qual precisa ser um destes: 4h, 8h, 16h, 32h, 64h (ou seja, a tecnica do dobro do dobro de 1 turno ate 1 sprint de 15 dias).
3. Ter uma data de entrega (o que sugere que vai ter um FixVersion de entrega). Nada impede que esse FixVersion seja "Unscheduled", ou seja, nao se sabe quando ela vai ser entregue - mas como se diz no PMBOK - "sabemos que nao sabemos quando ela vai ser entregue".
4. Ter uma prioridade (ou Rank no Scrum) perante as outras features no projeto, ou seja, ela tem um indice de importancia e interesse para o PO.
Performers
Gerente de Projetos, Arquiteto, Projetista, Designer, Usuario Lider
Description
A feature está estimada e é parte da WBS do projeto, e agora vai ser detalhada tecnicamente.
Nesta etapa de projeto, a feature será projetada, arquitetada e esmiuçada nos mínimos detalhes, pois é com base nesse projeto técnio que ela será construída.
Nesse ponto, a feature precisa estar exatamente como o PO a deseja.
O projeto técnico envolve tanto o Time (na figura, geralmente, do analista ou projetista responsável - o Chief Programmer, mas também envolvendo os outros recursos do time, como arquiteto, scrum master, desenvolvedores, e outros), quanto - e principalmente - o PO, e portanto ambos trabalham em sitonia, buscando detalhar cada aspecto relevante para a Feature representar o fidedigno do que o PO deseja.
O projeto técnico está completo, e a Feature somente pode sair desse status se:
1. Possuir um Caso de Uso, descrito segundo o padrão OBJETIVO; ATOR PRINCIPAL, ENVOLVIDOS E EXPECTATIVAS; PRE-CONDICOES; EVENTOS DE DISPARO; FLUXO PRINCIPAL, FLUXOS ALTERNATIVOS; POS-CONDICOES; EXCECOES)
2. Possuir uma lista de requisitos associados
3. Possuir um projeto de dominio, que descreve as Classes e Operacoes relacionadas (geralmente, um Diagrama de Classes)
4. Possuir um projeto de interface de usuario (geralmente uma tela, mas nem sempre), que identifique claramente os pontos de interacao e elementos envolvidos e tambem a parte navegacional do sistema (a IU em relacao as outras IU do sistema, menus, telas, validacoes, etc).
5. Possuir um projeto de implantacao e comunicacao, que descreve como a Feature deve ser empacotada e disponitilizada no sistema frente a estrutura e arquitetura da aplicacao.
6. Possuir um projeto de teste associado, incluindo teste unitario (a Feature funcionando), teste integrado (a Feature funcionando em conjunto com outras Features dentro do seu Servico), e funcional (a Feature em uso dentro do sistema final, sendo utlilizada pelo usuario final do sistema)
Observa-se que nesse ponto, o projeto tecnico segue o padrao 4+1 (porem ajustado), ou seja, a parte 1 é o quadrante logico (o Caso de Uso, os Requisitos e os Testes), a parte 2 é o nível de desenvolvimento (o Projeto de IU e o Diagrama de Classes), a parte 3 é o quadrante físico (o Diagrama de Implantacao ou Comunicacao) e a parte 4 é o quadrante de processo (ou de processamento, que envolve os famosos requisitos nao funcionais e a questao arquitetural, onde na verdade, o projeto tecnico da Feature precisa ser encaixado na arquitetura da aplicacao de forma transparente, e por isso esse quadrante pode ser minimizado no projeto tecnico, de forma que ele pode ser interpretado e implementado como uma lista de requisitos diferenciado - esteriotipo "nao funcional" por exemplo - na propria lista de requisitos da Feature.).
Caso o projeto técnico mostre discrepância em relação ao planejado (complexidade, tempo, etc), á Feature precisa retroceder no worfklow para a etapa de planejamento.
Isso pode ocorrer na primeira tentativa de projeto técnico, ou mesmo depois que este já foi finalizado uma vez e a construção tenha sido iniciada ou mesmo já em validação (etapa de validação).
Logo, fica subentendido que uma Feature nunca vai estar fora de sintonia em relação ao plajemaneto do projeto, seja estimada "para mais" ou estimada "para menos".
É responsabilidade do Chief Programmer "sentir" essa discrepância e reportar ao ScrumMaster e PO essa divergência para que a Feature volte para a etapa de planejamento.
Somente com esse projeto tecnico, esta apta a passagem para a próxima etapa de construção.
Performers
Description
A construcao é a realizacao do projeto tecnico.
Aqui, o Time trabalha continuamente, produzindo a feature, testando-a continuamente e evoluindo sua funcionalidade constantemente.
A presenca do PO aqui também é válida e muito importante, pois ele vai ajustando arestas e complmenetando informações durante a construção da Feature, o que vai minimizar quaisquer problemas na etapa posterior de validação funcional.
O Chief Programmer (ou Projetista ou Analista responsável) é o recurso que constanmente monitora e "puxa" o desenvolviemento da feature junto ao time, reportando o andamento diariamente durante as reuniões Stand Up de avaliação do Scrum.
Durante a construção é plausível que o projeto técnico mostre-se inadequado. Então, nesse caso, descarta-se totalmente o avanço na construção e esta deve retornar para o projeto técnico.
Observa-se assim que a Feature pode retroceder no worfklow. Assim, não deve ser construída uma Feature que esteja fora de conformidade com o seu projeto técnico.
Logo, Features que não podem ser construídas de forma avessa ao seu projeto técnico (seja porque o projeto técnico é inconsistente ou incompleto, seja porque ela está agredindo outra feature, seja porque o PO não está satisfeito com a Feature ou qualquer outro evento).
Em todos esses casos, a Feature retrocede para o projeto técnico.
É responsabilidade do Chief Programmer em conjunto com o Time reportar essas divergências de implementação frente ao projeto técnico.
Se o projeto técnico está OK, a feature é dada como construída está apta para evoluir no workflow de validacao se, e se:
1. Todos os testes unitários e integrados estiverem consistentes.
2. O PO deu seu OK na Feature durante o processo de homologação do sistema.
Performers
Description
Aqui, a Feature já foi construída e está em concordância com o projeto técnico.
Nessa etapa, o PO em conjunto com seus usuários finais realiza os testes de aceitação da Feature, os chamados testes funcionais.
Nesse ponto, é esperado que estes testes sejam balizados pelo Casos de Uso associado à Feature, bem como a lista de requisitos que a norteiam, o projeto de IU associado e os testes funcionais atrelados.
Caso qualquer inconsistência apareça, a Feature precisa retroceder para a etapa de Construção, e, eventualmente, dessa para outras etapas anteriores, conforme descrito nas outras etapas.
É responsabilidade do PO, em cojunto com os usuários finais e o Chief Programmer realizar estes testes.
Qualquer anomalia ou inconsistência de funcionamento no teste funcional deve produzir um item de correrção de Feature, e ser ligado (linkado como derivação da Feature) para entrar no pipeline de correção do projeto.
Uma Feature somente pode sair da etapa de validação com o OK formal do Product Owner sobre ela, o que pode ser feito na ferramente de controle do projeto ou então através de relatórios de entrega, tanto faz, mas é explicitamente necessária essa aprovação formal.
Performers
